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(54) Method and apparatus for transmitting data over data bus 



(57) A method and apparatus for transmitting data 
among devices connected to a serial data bus at maxi- 
mum speeds are disclosed. Each device may be capa- 
ble of transmitting data at several speeds. A transmitting 
device first transmits a data packet to a target recipient 
device at a maximum transmission speed of the trans- 
mitting device. If an acknowledgement signal confirming 
receipt of the initial data transmission is received from 
the target recipient, then the transmission speed for sub- 
sequent data packet transmissions is set to the speed 
of the just-transmitted data. Otherwise, the transmission 
speed is reduced and the process is repeated. Once an 
acknowledgement is received and the speed is set, the 
speed may be stored in a memory of the transmitting 
device for use in future communications with the recip- 
ient device. The process is repeated to establish maxi- 
mum suitable transmission speeds to other target de- 
vices connected to the bus. Embodiments of the present 
invention have particular utility when used in conjunction 
with an IEEE 1394 serial bus interface in the absence 
of a bus manager. Following a bus reset operation in 
which the memory of each device is cleared, individual 
devices reestablish appropriate data transmission 
speeds to each of the other devices by transmitting 
packets at varying speeds, if necessary, until acknowl- 
edgements are received. 
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Description 

[0001] The present invention relates to a method and 
apparatus for transmitting data over data bus. An illus- 
trative embodiment of the present invention relates gen- 
erally to data communications, and more particularly to 
a technique by which individual devices connected to a 
data bus can each transmit data to other devices at a 
maximum speed. 

[0002] As "smart" devices have proliferated in recent 
years, a trend is emerging in which everyday electronic 
devices such as video tape recorders (VTRs), televi- 
sions, personal computers, etc., can communicate with 
one another via connection to a common data bus. 
Among the many considerations in performing such da- 
ta communication is the selection of appropriate data 
transmission speeds. When devices connected to a 
common bus have differing data communication speed 
capability, it is necessary to select a data transmission 
speed at which a transmitting end can transmit data and 
a receiving device can receive data. Moreover if there 
is another apparatus (relay apparatus) between the 
transmitting and receiving devices, it is necessary to se- 
lect a data transmission speed at which the relay appa- 
ratus can operate. 

[0003] An international I/O connection standard, 
namely, the IEEE 1394-1995 serial bus standard, has 
been promulgated to provide a universal protocol for da- 
ta communications over a serial bus. This standard de- 
fines a digital interface for data communications, there- 
by eliminating the need for an application to convert dig- 
ital data to analog data before it is transmitted across 
the bus. Likewise, a receiving application will receive 
digital data from the bus rather than analog data, and 
will therefore not be required to perform A/D conversion. 
[0004] The IEEE 1 394 standard has been adopted to 
implement an inexpensive high-speed architecture 
which supports both asynchronous and isochronous for- 
mat data transfers. Isochronous data transfers are real- 
time transfers which take place such that the time inter- 
vals between significant instances have the same dura- 
tion at both the transmitting and receiving applications. 
Each packet of data transferred isochronously is trans- 
ferred in its own time period. An example of an applica- 
tion for the transfer of data isochronously would be from 
a video recorder to a television set. The video recorder 
records images and sounds and saves the data in dis- 
crete chunks or packets. The video recorder then trans- 
fers each packet, representing the image and sound re- 
corded over a limited time period, during that time peri- 
od, for display by the television set. Multiple channels 
are provided for isochronous data transfer between ap- 
plications. A six bit channel number is broadcast with 
the data to ensure reception by the appropriate applica- 
tion. This allows multiple applications to simultaneously 
transmit isochronous data across the bus structure. 
Asynchronous transfers are traditional data transfer op- 
erations which take place as soon as possible and trans- 



fer an amount of data from a source to a destination. 
[0005] FIG. 19 is an arrangement of a number of de- 
vices with information processing capability connected 
to IEEE 1394 serial buses. In this example, IEEE 1394 

5 serial buses 10-1 to 10-7 interconnect a personal com- 
puter (PC) 1, an integrated receiver/decoder (IRD) 2. a 
digital video tape recorder (digital VTR) 3, an editor 4, 
a MiniDisk (MD) deck 5, a monitor 6, a hard disk drive 
(HDD) 7 for storing image data and audio data, and a 

10 server 8. These devices satisfy the IEEE 1 394 standard 
as well as the IEC 61883 standard providing audio-vis- 
ual (AV) data transmission based on IEEE 1394. Each 
connected device constitutes a node (i.e. , an accessible 
unit) in IEEE 1394, and each device has its own maxi- 

15 mum data communication speed at which it is capable 
of performing data transmission and reception. Accord- 
ing to the IEEE 1 394 standard, the maximum speed for 
any given device can be either 98.308 Mbps, 196.608 
Mbps or 392.216 Mbps, designated herein as speeds 

20 si 00, S200 and S400, respectively. The maximum data 
communication speed for a particular device is, of 
course, dependent upon that device's hardware capa- 
bilities. A device can always transmit and receive data 
at lower speeds: for instance, a device having S400 ca- 

25 pability can communicate at S100 or S200 if necessary. 
Data transmission based on S100 can be performed by 
all apparatuses satisfying the IEEE 1394 standard. 
When devices with different maximum communication 
speeds are connected to a common bus, a transmitting 

so device must transmit at a transmission speed that can 
be relayed by another device operating as a relay. 
[0006] FIG. 20 depicts illustrative maximum data 
communication speeds for the devices of FIG. 1 9. Thus, 
PC 1 has a maximum data communication speed of 

35 S400: editor 4 has a maximum speed of S200: and so 
forth. For example, both the MD deck 5 and the digital 
VTR 3 are S400 devices, and do not connect to an ap- 
paratus for transferring data between them, whereby 
they would always communicate with each other at 

40 S400 speed. On the other hand, if a slower device is 
operating as a relay for a faster device, the faster device 
cannot communicate through the relay device to other 
devices at its maximum speed capability. For instance, 
both the MD deck 5 and the PC 1 can transmit at S400, 

45 but since the receiver/decoder 2 with only S200 capa- 
bility is connected therebetween in their transmission 
path, they can only communicate at S200 speed. 
[0007] The IEEE 1394 serial bus standard defines a 
function called a "bus manager" which performs the 

50 services of: advanced bus power management: mainte- 
nance of a speed map of the data communication speed 
capabilities of the bus-connected devices: maintenance 
of a topological map of the connected devices: and bus 
optimization based on information obtained from the 

55 topological map. As part of the bus optimization, the bus 
manager determines the maximum speeds at which 
each device is able to transmit data in consideration of 
the current topology. The bus manager provides each 
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device with maximum data transmission speed informa- 
tion in accordance with the optimization. Thus, a device 
connected to the IEEE 1394 serial bus sets, based on 
the information from the bus manager a data transmis- 
sion speed for transmission of data to a particular device 
connected to the bus. In this manner communication is 
executed at a maximum data transmission speed ena- 
bling communication. When a new device is added to or 
removed from the bus, the speed map as well as the 
data speed information provided to the bus-connected 
devices are updated. 

[0008] The IEEE 1 394 standard also requires an en- 
tity called an isochronous resource manager. This entity 
functions to provide facilities for: allocation of iso- 
chronous bandwidth: allocation of channel numbers: 
and selection of a cycle master. 

[0009] According to the iEEE 1394 serial bus stand- 
ard : the existence of the bus manager is optional. How- 
ever, if a bus manager is absent, the isochronous re- 
source manager exercises a subset of the management 
responsibilities normally assumed by the bus manager. 
(The latter circumstance assumes that isochronous traf- 
fic is to take place. If tftere is no isochronous resource 
manager, no isochronous traffic is allowed.) In this case, 
if devices on the IEEE ( 1394 serial bus have S200 or 
higher speed capability, and a device acting as a relay 
also has S200 or higher capability, the devices must 
nevertheless perform initial communication based on 
S100 because they do not obtain information on a suit- 
able data transmission speed to an apparatus at a re- 
ceiving end. Thus, when no bus manager exists, a prob- 
lem arises in that the devices connected to the IEEE 
1394 serial bus use a minimum speed to perform data 
transmission. 

[0010] Aspects of the present invention are set out in 
the claims to which attention is invited. 
[0011] An embodiment of the present invention seeks 
to provide a method for transmitting data among devices 
connected to a common data bus at maximum speeds. 
[0012] Another embodiment of the present invention 
seeks to provide a method for transmitting data among 
devices connected to an IEEE 1394 serial data bus, 
even if no bus manager is present. 
[001 3] Still another embodiment of the present inven- 
tion seeks to provide a device connectable to a data bus, 
which is capable of determining appropriate transmis- 
sion speeds for transmission of data to other devices 
connected to the bus. 

[001 4] Yet another embodiment of the present inven- 
tion seeks to provide an improved method for data com- 
munication on a data bus. 

[0015] In accordance with an illustrative embodiment 
of the invention, there is provided a method and appa- 
ratus for transmitting data among devices connected to 
a data bus at maximum speeds. Each device may be 
capable of transmitting data at a number of speeds. A 
transmitting device first transmits a data packet onto the 
bus with ID information of a target recipient device, at 



the maximum transmission speed of the transmitting de- 
vice. If an acknowledgement signal confirming receipt 
of the initial data transmission is received from the target 
recipient device, then the transmission speed for sub- 

s sequent data transmissions to that device is set to the 
speed of the just-transmitted data. Otherwise, the trans- 
mission speed is reduced and the process is repeated. 
Once an acknowledgement is received and the speed 
is set, the speed may be stored in a memory of the trans- 

10 mitting device for use in subsequent data transmissions 
to the recipient device. The subsequent data transmis- 
sions may be asynchronous and/or isochronous data 
transmissions. The process is repeated to establish 
maximum suitable transmission speeds to other target 

is recipient devices connected to the bus. 

[0016] Embodiments of the present invention have 
particular utility when used in conjunction with an IEEE 
1394-1995 serial bus interface in the absence of a bus 
manager. Following a bus reset operation in which the 

20 memory of each device containing transmission speed 
information is cleared, individual devices reestablish ap- 
propriate data transmission speeds to each of the other 
devices by transmitting packets at varying speeds, if 
necessary, until an acknowledgement is received from 

25 each respective device. 

[0017] For a better understanding of the present in- 
vention, reference will now be made by way of example 
to the accompanying drawings in which: 

30 FIG. 1 is a block diagram of hardware within a digital 
VTR: 

FIG. 2 is a functional block diagram of a digital VTR 
according to an embodiment of the present inven- 
tion: 

35 FIG. 3 is a block diagram illustrating functions per- 
formed in accordance with the IEEE 1 394 protocol: 
FIG. 4 is a diagram showing an asynchronous su- 
baction structure: 

FIG. 5 is a block diagram showing the condition of 
40 nodes initiating arbitration: 

FIG. 6 illustrates the operation of a node that re- 
ceived a request signal: 

FIG. 7 is a block diagram illustrating the operation 
of a node as a root when it outputs a grant-signal: 
45 FIG. 8 illustrates the operation of a node that re- 
ceived a grant-signal and the operation of a node 
that received a deny-signal: 

FIG. 9 is a block diagram illustrating the condition 
of a node when it initiates data transmission: 
50 FIG. 10 illustrates message transmission and re- 
ception between link layers during asynchronous 
communication: 

FIG. 11 is a diagram showing an isochronous sub- 
action structure: 
55 FIG. -12 illustrates a cycle of data transmission 
among apparatuses connected based on IEEE 
1394: 

FIG. 13 depicts an example of an asynchronous 
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packet structure: 

FIG. 14 is a table illustrating main elements of an 
asynchronous packet: 

FIG. 15 depicts an acknowledge-packet structure; 
FIG. 1 6 is a table describing different acknowledge- 
ment codes of an asynchronous packet: 
FIG. 1 7 is a flowchart illustrating a process for trans- 
mitting data by a transmitting end device to a receiv- 
ing end device connected to a bus in accordance 
with an embodiment of the present invention: 
FIG. 18 is a flowchart illustrating another process 
for transmitting data in accordance with an embod- 
iment of the present invention; 
FIG. 19 shows an arrangement of various devices 
connected to IEEE 1394 serial buses: and 
FIG. 20 depicts an arrangement of devices of vari- 
ous data speed capability connected to a bus. 

[0018] Preferred embodiments of the present inven- 
tion will now be described in the context of an apparatus 
and method for performing high speed data transmis- 
sion on an IEEE 1394 serial bus. It is contemplated, 
however that the invention may be practiced in conjunc- 
tion with other data bus protocols. Thus : the following 
detailed description is for illustrative purposes only 
[0019] Referring now to FIG. 1 , a function block dia- 
gram of a digital video tape recorder (VTR) 3 is shown. 
Digital VTR 3 will be described hereafter as an illustra- 
tive information processing apparatus configured to 
transmit data at maximum speeds on a data bus to re- 
spective recipient devices in accordance with an em- 
bodiment of the present invention. The means em- 
ployed within VTR 3 to carry out the novel data commu- 
nication technique : however may be incorporated with- 
in any information processing apparatus connected to 
the bus. 

[0020] VTR 3 includes a recording/reproducing unit 
21 that records and reproduces data to/from a loaded 
videotape (not shown). A liquid crystal display (LCD) 23 
and a touch panel 24 are connected to an internal bus 
via an input/output (I/O) interface 22. The LCD 23 dis- 
plays display data supplied from the recording/repro- 
ducing unit 21 , a central processing unit (CPU) 25 : or 
an IEEE 1 394 interface 28. The touch panel 24 supplies 
I/O interface 22 with a signal in accordance with an op- 
eration by a user. 

[0021] CPU 25 executes various programs, including 
an application program to establish a suitable data 
transmission rate or rates for transmission of image : au- 
dio and other data to other devices connected to the bus. 
A read only memory (ROM) 26 stores fixed program da- 
ta and operation parameters used by CPU 25. Random 
access memory (RAM) 27 stores programs executed by 
CPU 25 as well as parameters that necessarily change 
during program execution. Interface 28 is an I/O inter- 
face configured in accordance with the IEEE 1394 
standard: and transfers data between the internal bus 
and one or more external IEEE 1 394 serial buses. (It is 



noted that when a plurality of buses such as 10-3 and 
10-4 of FIG. 19 are connected to the same device, the 
plurality of buses may be considered as part of a com- 
mon bus.) The internal bus is the vehicle by which data 

s is transferred among I/O interfaces 22 and 28, record- 
ing/reproducing unit 21 , CPU 25 : ROM 26 and RAM 27. 
[0022] FIG. 2 is a functional block diagram of a pro- 
gram that is executed mainly by CPU 25 in the digital 
VTR 3 (or other apparatus connected to the serial bus) 

w having the above-described hardware. Recording/re- 
producing unit 21 controls recording and reproduction 
of data to/from a mass media storage unit, e.g.. a vide- 
otape in this example. A communication speed setting 
unit (transmission speed setting means) 32 selects a 

1$ predetermined transmission speed from among trans- 
mission speeds 98.308 Mbps : 196.608 Mbps ; and 
392. 21 6 Mbps for data transmission to a target receiving 
end device connected to the bus. Speed setting unit 32 
requests a serial bus control unit (data transmission 

20 means) 35 to perform the data transmission at the se- 
lected transmission speed. An acknowledgement (ACK) 
detecting unit 33 (detecting means) detects an acknowl- 
edgement signal from the target receiving end device, 
which is sent to confirm receipt of a data transmission 

25 to that device by the VTR 3. Based on the reception sig- 
nal detected by the ACK-detecting unit 33 : the commu- 
nication speed setting unit 32 determines whether data 
can be transmitted to the target receiving end device at 
the transmission speed at which packets were transmit- 

30 ted. 

[0023] A communication speed storage unit 34 (trans- 
mission speed storage means) stores a list of maximum 
transmission speeds corresponding to the various de- 
vices connected to the bus. Each stored speed repre- 
ss sents the speed at which data can be suitably transmit- 
ted by VTR 3 to the associated device. The speeds are 
determined by speed setting unit 32 based on the ac- 
knowledgement signals sent from the respective recep- 
tion devices. Speed storage unit 34 clears the stored 
-to information when the IEEE 1 394 serial bus is "reconfig- 
ured" or "reset". (According to the IEEE 1 394 standard, 
the bus is automatically reset whenever a device is add- 
ed to or removed from the bus.) The serial bus controller 
35 has a communication procedure based on IEEE 
is 1 394 : and transmits data to other apparatuses connect- 
ed to the IEEE 1394 serial bus, or receives data and 
confirmation signals from the other apparatuses con- 
nected to the IEEE 1394 serial bus. 
[0024] A preferred method by which a data transmis- 
50 sion speed to a target reception device is determined by 
speed setting unit 32 will be described later with refer- 
ence to FIGS. 17 and 18. Briefly, the preferred method 
entails first transmitting data to a target recipient device 
at the maximum transmission speed of the transmitting 
55 device, VTR 3 in this example. If an acknowledgement 
to the initial data transmission is received from the target 
reception device, then the selected transmission speed 
is the maximum speed (e.g., speed S400): otherwise, 
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the next lower speed (S200) is selected as a candidate 
and an attempted data transmission is performed at 
S200. If an acknowledgement is received to the lower 
data speed transmission, then S200 is selected as the 
speed for future data transmissions; otherwise, speed 
S 1 00 is selected. The process is repeated when a trans- 
mission is attempted to another target device. Accord- 
ingly, maximum data communication speeds are set in 
an efficient manner without the need for a bus manager 
to provide the speed information. 

IEEE 1394 Communication Protocol 

[0025] For a better understanding of the applicability 
of the present invention to devices that communicate in 
accordance with the IEEE 1394 protocol certain as- 
pects of this protocol will now be described. Embodi- 
ments of a data communication method of the invention 
will be presented subsequently. 

[0026] FIG. 3 is a block diagram illustrating a function- 
al layer structure in accordance with the IEEE 1394 pro- 
tocol. The protocol defines a hierarchical structure com- 
prised of three layers -- a transaction layer 42 : a link 
layer 43 : and a physical layer 44. The three layers can 
be considered to exist in each node connected to the 
serial bus. The layers communicate with one another 
and each layer may communicate with an optional serial 
bus management entity 41 . The transaction layer 42 and 
the link layer 43 each communicate with another func- 
tional block (e.g., the recording/reproducing unit 31 
shown in FIG. 2). There are four types of transmission/ 
reception messages used in this communication: a re- 
quest: an indication; a response: and a confirmation. 
The arrows shown in Fig. 3 represent these communi- 
cations. Each communication in which ".req" is added 
to the end of an arrow name represents a request. Sim- 
ilarly, "ind" represents an indication, " resp" represents 
a response, and "conP represents a confirmation. For 
example, TR_CONT.req" represents a request commu- 
nication sent from the serial bus management 41 to the 
transaction layer 42. 

[0027] The transaction layer 42 satisfies a request re- 
sponse protocol required in the ISO/I EC 1 321 3 standard 
by providing : in response to a request from another func- 
tional block (e.g., the communication speed setting unit 
32 shown in FIG. 2), asynchronous data transmission 
to a target device connected to the bus. The transaction 
layer 42 processes data for asynchronous transmission, 
but does not perform processing for isochronous trans- 
mission for transmitting data such as images and sound. 
I n accordance with the transaction layer 42 protocol, da- 
ta is transmitted asynchronously among devices using 
three transactions -- a read transaction, a write transac- 
tion, and a lock transaction. The lock transaction is used 
to eliminate a problem caused by a split transaction con- 
sisting of two or more packet transmissions in the link 
layer 43. 

[0028] The link layer 43 performs operations such as 



data transmission using acknowledge-signals, confir- 
mation of data errors, and data framing. A request for 
isochronous data transmission service from another 
functional block (e.g., the recording/reproducing unit 31 
5 shown in FIG. 2) is made to the link layer 43. Transmis- 
sion of one packet by the link layer 43 is called a "sub- 
action". There are two types of subactions - an asyn- 
chronous subaction and an isochronous subaction. In 
an asynchronous subaction that transmits node identi- 
fy fication (node I D) data specifying a node and an address 
in the node, the node that received data responds using 
an acknowledge-signal. In an isochronous broadcast 
subaction that sends data to all nodes in the IEEE 1 394 
serial bus, nodes receiving data do not respond using 
is an acknowledge-signal. Data in the isochronous subac- 
tion is transmitted periodically at a constant cycle, within 
a selected channel, and no acknowledge-signal is used 
for a response. 

[0029] FIG. 4 is a diagram showing an arrangement 

20 of asynchronous subactions specifying node IDs and 
addresses in the nodes. In this example, during the time 
period denoted as "subaction 1:request", a first prede- 
termined node transfers a packet to request a second 
predetermined node to perform a read or write opera- 

25 tion. In the interval denoted as "subaction 2:response'\ 
the second node responds to the request from the first 
node. The asynchronous subactions consist of arbitra- 
tion sequences 51-1 and 51-2, data packet transmis- 
sions 52-1 and 52-2, and acknowledgments 53-1 and 

30 53-2. A node that wants to transfer an asynchronous 
packet requests the physical layer 44 in an arbitration 
sequence period such as 51-1 or 51-2 to control the 
IEEE 1394 serial bus. A node that succeeds at arbitra- 
tion transfers an asynchronous packet in a data packet 

35 transmission period as 52-1 or 52-2. A node that re- 
ceived the asynchronous packet specifying its receiver 
node ID sends an acknowledge-signal in an acknowl- 
edgment period as 53-1 or 53-2 to the node that trans- 
mitted the packet. The asynchronous subactions are di- 

40 vided by periods called "subaction gaps" 54-1 to 54-3. 
The data packet transmissions 52-1 and 52-2, and the 
associated acknowledgments 53-1 and 53-2 are divided 
by periods called "ACK gaps" 55-1 and 55-2. 
[0030] The operation of the physical layer 44 of each 

45 node in the period of arbitration sequences 51-1 and 
51 -2 will now be described with reference to FIGS. 5-9. 
FIG. 5 illustrates a condition of nodes connected to the 
IEEE 1 394 serial bus, with certain nodes requesting da- 
ta transmission and initiating arbitration. (The connec- 

50 tion condition in FIG. 5 differs from that shown in FIG. 
19.) It is assumed that after detecting subaction gaps, 
nodes #0 and #2 simultaneously output request signals 
to their parent nodes, i.e., nodes #4 and #3, respectively. 
Whenever a parent node (first parent) receives a re- 

55 quest from a child node, the parent node, outputs the 
request to its parent node (second parent), if one exists, 
unless anotherchild of the first parent had already made 
a request. That is, the first parent outputs the request 
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from the child that made the request first, and simulta- 
neously sends a deny signal to the other child nodes. 
[0031] Therefore: as shown in FIG. 6, since node #3 
received a request signal from node #2, it routes this 
request to its parent, node #4, and simultaneously 
sends a deny signal to its other child, node #1. By way 
of example, in the case where a request from node #0 
reaches node #4 earlier than the request from node #3 
(which stems from the node #2 request), node #4 out- 
puts a deny-signal to node #3. It is noted here that in 
this example, nodes #0, #1 and #2 are designated as 
leaf nodes because they connect to only one other node. 
Node #3 is a branch node and node #4 is a root node. 
In general, the selection of the root node is not topology 
dependent, and it is even acceptable for the root node 
to also be a leaf. The standard requires, however that 
the isochronous cycle master also has to be the root, 
since the root has the highest natural priority. Also, the 
node that has all of its connected ports identified as chil- 
dren becomes the root. 

[0032] As shown in FIG. 7. node #4 as a root outputs 
a grant-signal to node #0, which had output the earliest 
request signal. When a root node provides a grant signal 
to one of its children, it simultaneously outputs deny- 
signals to the remainder of its children. As such, root 
node #4 sends a deny-signal to the branch node #3 in 
the current example. Branch node #3, upon receiving 
this deny-signal, discontinues the output of the request 
signal to the root node, and sends deny-signals to each 
of its children, nodes #1 and #2. Node #2, upon receiv- 
ing the deny signal, terminates the output of its request 
signal as shown in FIG. 8. 

[0033] A node that receives a grant-signal in response 
to its request signal changes the request signal to a data 
prefix signal. In the current example, as shown in FIG. 
8, node #0 changes the request signal to a data prefix 
signal upon reception of the grant signal from the root 
node #4. When node #4 receives this data prefix signal, 
it terminates the output of the grant-signal, as illustrated 
in FIG. 9. A deny signal and a data prefix signal function 
similarly, in that whenever a node receives either a deny 
signal or a data prefix signal, it enters a receiving mode. 
Hence, nodes #1 to #4 are all in their receiving modes 
before node #0 initiates data transmission. Data output 
from node #0 is transmitted to all the nodes along the 
data prefix signal direction shown in FIG. 9. 
[0034] FIG. 10 illustrates the operation of the link lay- 
ers 43 when they perform asynchronous message 
transmission and reception, in which node IDs and node 
addresses are specified. The transaction layer 42 of a 
transmitting node transmits a request message to that 
node's link layer 43. The transmitting node link layer 43 
then transmits data packets to the target receiving 
node's link layer 43 via the physical layers of the trans- 
mitting and receiving nodes and the IEEE 1394 serial 
bus. Next, the receiving end link layer 43 sends an in- 
struction message to the receiving end transaction layer 
42, which in turn acknowledges receipt of the original 



re q Ues t by transmitting an acknowledgement 53-1 back 
to the transmitting end link layer via the physical layers 
and the serial bus. The transmitting end link layer 43 
responds to the acknowledgment by transmitting a con- 
5 firmation message to the transmitting end transaction 
layer 42. 

[0035] Thus, in the above-described manner, when 
the transmitting end node receives an acknowledge- 
ment, it knows that data communication with the intend- 
to ed recipient node has been established, and can pro- 
ceed asynchronously. On the other hand, when the 
transmitting end cannot detect acknowledgment, it de- 
termines that the case is ACK missing, meaning that the 
attempted communication has failed. 

75 [0036] Turning now to FIG. 11 , a timing diagram illus- 
trating isochronous subactions is presented. Iso- 
chronous data transmission is performed in packets, 
with each packet transmitted during a specific time slot 
or "channel 0 , e.g., the first to third channels depicted. 

20 Consecutive channels such as the first and second 
channels can support data packet transmission either 
by different nodes or by the same node. The iso- 
chronous subactions consist of arbitration sequences 
61-1 to 61 -3 and data packet transmissions 62-1 to 62-3 

25 in the respective channels. A node that wants to transmit 
isochronous packets requests its physical layer 44 to 
control the IEEE 1394 serial bus in an arbitration se- 
quence period. The operation of each node in the iso- 
chronous subaction is identical to the above-described 

30 operation of a node in the asynchronous subaction. 
[0037] A transmitting node that succeeds at arbitra- 
tion during an arbitration sequence as 61 -1 immediately 
transmits a data prefix and an isochronous data packet 
as 62-1 in the succeeding time period. The isochronous 

35 subactions are divided by isochronous gaps 63-1 to 
63-4, which are shorter than the above-discussed asyn- 
chronous subaction gaps 54-1 to 54-3 of FIG. 4. A node 
that desires to transmit data isochronously will immedi- 
ately arbitrate for the bus following the detection of an 

40 isochronous gap. A node desiring to transmit data asyn- 
chronously must watt for an asynchronous gap to occur. 
Since the isochronous gap is shorter than the asynchro- 
nous gap, this gives priority to isochronous communica- 
tion over asynchronous communication. 

45 [0038] FIG. 12 is a diagram depicting a cycle of data 
transmission among apparatuses connected based on 
the IEEE 1394 standard. Data is divided into packets 
and transmitted using a 125 ps cycle as a reference. 
This cycle is created based on a cycle start signal sup- 

50 plied from a node having a cycle master function. An 
isochronous packet reserves a band (i.e., time slot) nec- 
essary for transmission from the start of all cycles. 
Therefore, for isochronous transmission, data transmis- 
sion in a constant time interval from the start of the cycle 

55 is guaranteed. However if a transmission error occurs, 
data is lost because no protection system is used. Once 
all nodes that desire to transmit data isochronously have 
done so, e.g., in channels J to N, the bus will stay idle 
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long enough for an asynchronous subaction gap to ap- 
pear. When this occurs, a node desiring to transmit 
asynchronous data can arbitrate for the bus and then 
transmit an asynchronous packet when arbitration suc- 
ceeds. Asynchronous transmission uses acknowledge- 
and retry-signals to guarantee secure transmission, but 
cannot set transmission timing to be constant. 
[0039] Returning to FIG. 3, the physical layer 44 con- 
verts logical symbols used in the link layer 43 into elec- 
trical signals. The physical layer 44 uses arbitration to 
ensure that only one node initiates data transmission. It 
executes the reconfiguration of the IEEE 1 394 serial bus 
in accordance with bus resetting, and automatically as- 
signs physical IDs. 

[0040] The serial bus management entity 41 realizes 
basic bus-control functions, and provides the Control & 
Status Register Architecture (CSR) of the ISO/IEC 
13212 standard. Serial bus management entity 41 has 
the functions of a node controller an isochronous re- 
source manager and a bus manager. The node control- 
ler controls node condition, node IDs: etc., and controls 
the transaction layer 42, the link layer 43, and the phys- 
ical layer 44. To perform isochronous communication, 
at least one of the devices connected to the IEEE 1 394 
serial bus must have the isochronous resource manager 
function. The bus manager is the highest function of the 
respective functions, and its object is to optimally use 
the IEEE 1394 serial bus. The existence of the iso- 
chronous resource manager and the bus manager is op- 
tional. However, according to the standard, if there is no 
bus manager, the isochronous resource manager exer- 
cises a subset of the management responsibilities nor- 
mally assumed by the bus manager. Of course, if the 
isochronous resource manager is absent as well, only 
asynchronous data communication can be carried out. 
[0041] Referring now to FIG. 1 3, an exemplary struc- 
ture of an asynchronous packet 52-1 or 52-2 is shown. 
The packet begins with a destinationJD which is the ID 
of the intended receiving node, and ends with a 
data_CRC field. The asynchronous packet is used to 
write data sent as a payload to an address beginning 
with a predetermined offset receiver address. The char- 
acteristics of various elements of an asynchronous 
packet are presented in the table of FIG. 14. The items 
listed in the column under the header "NAMES" corre- 
spond to the names of the asynchronous packet ele- 
ments shown in FIG. 1 3. The "CONTENTS" column pro- 
vides a short description of each element. A node that 
may receive an asynchronous packet reads information 
stored in the receiver ID. When the read ID matches the 
ID of the node, the node proceeds to receive the con- 
tents of the asynchronous packet. The receiving node 
then responds to the transmitting node based on the in- 
formation stored in the transmitter ID by sending an ac- 
knowledge-packet to the transmitting node (that trans- 
mitted the asynchronous packet). 
[0042] FIG. 1 5 illustrates the structure of an acknowl- 
edge-packet 53-1 or 53-2 of FIG. 4. The four least sig- 



nificant bits of the acknowiedge-packet are allocated for 
parity bits. The four most significant bits of the packet 
are used as an "ack_code M . Depending on its code val- 
ue, the ack_code indicates one of the following condi- 

s tions: completion: pending; three types of busy: or two 
types of data error. These conditions are explained with 
reference to FIG. 16. A node at a transmitting end trans- 
mits an asynchronous packet to a predetermined node 
at a receiving end at a predetermined data transmission 

io speed. When the transmitting end receives a packet 
with any one of the ack-codes shown in FIG. 16 from 
the receiving end, it determines that data transmission 
to the node at the receiving end node can be performed. 
(The receiving end node is denoted as "Transmitter 

is Node" in FIG. 16.) When the receiving end node trans- 
mits an asynchronous packet including any one of the 
ack_codes shown in FIG. 16, this indicates that the re- 
ceiving end node recognized the received asynchro- 
nous packet and supports the transmission speed of the 

20 asynchronous packet. As mentioned earlier according 
to the IEEE 1 394 standard, if a bus manager is present, 
it maintains a speed map for the current topology of in- 
terconnected nodes, and supplies the predetermined 
speed information to each of the nodes. In the absence 

25 of a bus manager the predetermined speed at which 
each node transmits data is the minimum speed, S100. 

Embodiments of Data Transmission Speed 
Optimization Method 

30 

[0043] FIG. 17 is a flowchart illustrating an embodi- 
ment of a method for transmitting data among devices 
connected to a data bus at maximum speeds in accord- 
ance with the present invention. This embodiment has 

35 particular utility for environments in which a bus manag- 
er is absent. If a bus manager is present, this method 
would preferably supersede the standard technique of 
the bus manager supplying each node with predeter- 
mined speeds at which to transmit data. The method dis- 

J0 closed herein involves the transmission of an asynchro- 
nous packet to a target recipient device at a maximum 
speed. If a suitable acknowledgement is received, sub- 
sequent data transmission to the recipient device, i.e., 
asynchronous and/or isochronous, is performed at the 

•*s maximum speed. Otherwise, the transmission speed is 
gradually lowered until a suitable acknowledgement is 
received. 

[0044] By way of example to illustrate the method, it 
is assumed that the digital VTR 3 of FIGS. 1 and 2 is 

so connected to a data bus such as an IEEE 1394 bus, and 
desires to transmit data to a target recipient device 
(node) connected to the bus. It is understood, however 
that any type of device connected to the serial bus can 
practice the method with suitable software and/or hard- 

55 ware to implement the respective functions. 

[0045] In step S11 : the communication speed setting 
unit 32 requests the serial bus controller 35 to set a max- 
imum transmission speed at which transmission can be 
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performed. Thus, for example, if the transmitting node 
is capable of S400 speed, the speed will initially set to 
S400 regardless of the topology of the nodes connected 
to the bus. In step S1 2, the serial bus controller 35 trans- 
mits an asynchronous packet to the target recipient de- 
vice at the set transmission speed by including the target 
device's node ID ; etc., in the packet transmission. This 
asynchronous packet may be the same as packet 52-1 
of FIG. 4 in the IEEE 1394 based system, and would 
follow a successful arbitration 51-1. In step S13, the 
ACK-detecting unit 33 determines whether an acknowi- 
edge-packet has been received from the target recipient 
device. Successful receipt of an acknowledge-packet 
may be detected, for example, if a packet is received 
with one of the ack-codes in FIG. 16. If a suitable ac- 
knowledge-packet has been received, the process ends 
because the apparatus at the receiving end received the 
asynchronous data packet. In this circumstance, the 
transmission speed for subsequent data transmission 
from the VTR 3 to the recipient device is set at the speed 
of the packet that was acknowledged (i.e., S400 in this 
example if an acknowledgment is received in response 
to the maximum speed transmission). 
[0046] If in step S13 no acknowledge-packet is re- 
ceived, the ACK-detecting unit 33 sends, to the commu- 
nication speed setting unit 32, an Ack-missing message 
indicating that no response was received from the target 
recipient. When communication speed setting unit 32 
receives this message, it determines whether or not the 
present transmission speed set by the serial bus con- 
troller 35 is a minimum value (98.308 Mbps based on 
S100). If not, the routine flows to step S15 where the 
communication speed setting unit 32 requests the serial 
bus controller 35 to set the next lower transmission 
speed, e.g., 196.608 Mbps (S200). Once the lower 
transmission speed is set, the routine proceeds to step 
S12, and the process is repeated. If in step S14 the 
present transmission speed is minimum, the routine re- 
turns to step S12, and the process is performed again 
at the minimum speed as a retry operation. After a pre- 
scribed number of retries at the minimum speed, a com- 
munication failure error message is typically generated. 
[0047] In the above example, it was assumed that the 
transmission speed is lowered after only one data trans- 
mission attempt at a particular transmission speed. This 
approach can be modified by allowing two or more at- 
tempts at each speed before reducing the speed. 
[0048] As described above, in accordance with the 
above embodiment, a device such as the digital VTR 3 
connected to a serial data bus can perform data trans- 
mission to a predetermined apparatus on the bus at a 
maximum transmission speed at which data transmis- 
sion can be performed. When the transmitting device 
desires to transmit data to a second recipient device, 
the method of FIG. 17 is preferably repeated for the sec- 
ond device. It is noted that in the method of FIG. 17, 
once data transmission to a target recipient device is 
completed at the set speed, the speed information for 



that recipient device can be either stored for future data 
transmission to that device (assuming no changes to the 
node connection topology), or, erased. In the latter case, 
the process of FIG. 17 is repeated each time a data 

5 transmission to the target device is to be performed. 
[0049] FIG. 18 is a flowchart illustrating a similar 
method for performing asynchronous data transmission 
to another apparatus by a node such as digital VTR 3 
connected to a data bus. This method is essentially a 

10 special case of the method of FIG. 17. That is, once a 
maximum transmission speed to a specific recipient de- 
vice is determined, that speed is stored in a memory of 
the transmitting device, and used for future data trans- 
missions to the specific recipient device. However, if a 

is bus reconfiguration is performed, the speed information 
is erased from the memory. Typically, a bus reconfigu- 
ration is performed whenever a device is added to or 
removed from the bus. 

[0050] The method of FIG. 18 assumes that the trans- 

20 mining node maintains a memory, e.g., communication 
speed storage unit 34, containing stored transmission 
speeds for some or all of the other devices connected 
to the bus. That is, each entry for stored transmission 
speed associated with a recipient device is a maximum 

25 speed suitable for data transmission from the transmit- 
ting node to that recipient device. When a bus reconfig- 
uration is performed, the speed information is cleared 
from the memory of each device connected to the bus. 
Once this occurs, the method of FIG. 18 may be per- 

30 formed immediately by each device connected to the 
bus (in sequence) so as to immediately establish suita- 
ble transmission speeds for subsequent communica- 
tions. Alternatively, the method can be performed by a 
given device just prior to when it is desired to transmit 

35 data to an intended recipient device. In the latter case, 
the given device's memory containing the stored trans- 
mission speeds may remain partially or completely emp- 
ty well after a bus reconfiguration has occurred, with the 
memory gradually becoming filled with speed informa- 

40 tion each time a data packet is transmitted to, and ac- 
knowledged by, another recipient device. 
[0051] Accordingly, in step S21. the communication 
speed setting unit determines whether the reconfigura- 
tion of the serial bus has been executed. If it has. then 

^5 jn step S22 the communication speed setting unit 32 re- 
quests the serial bus controller 35 to set the maximum 
transmission speed at which transmission can be per- 
formed, e.g., S400. Otherwise, the routine proceeds to 
step S23, where the communication speed setting unit 

so 32 reads from storage unit 34 a stored transmission 
speed corresponding to the target recipient device. This 
stored speed is a speed previously determined at which 
data transmission to the target recipient device can be 
performed. Speed setting unit 32 then requests the se- 

55 rial bus controller 35 to set the read transmission speed. 
[0052] With the transmission speed thus set in ac- 
cordance with either the stored transmission speed for 
the target recipient device or the maximum transmission 
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speed of the transmitting node, the routine proceeds to 
step S24 where an asynchronous data packet is trans- 
mitted at the set speed. Steps S24 to S27 are the same 
as steps S12 to S15 of FIG. 17, and thus a description 
thereof is omitted. In step S25, if it has been determined 
that an acknowledge-packet has been received, the 
process proceeds to step S28. In step S28 ; the ACK- 
detecting unit 33 transmits, to the communication speed 
setting unit 34, a message requesting the communica- 
tion speed setting unit 34 to store (or re-store) an entry 
for the recipient device that received the asynchronous 
data packet, and its transmission speed, i.e., the speed 
of the packet that was acknowledged. Thus, the stored 
speed is the speed at which data should be subsequent- 
ly transmitted to the recipient device, and represents the 
maximum suitable speed for the subsequent transmis- 
sion. This completes the process for the target recipient 
device, at which point asynchronous and/or iso- 
chronous data packets can be transmitted to the target 
recipient at the determined speed, or the routine can be 
repeated for another target recipient device. 
[0053] As described above, by determining and stor- 
ing a maximum transmission speed for an apparatus at 
a receiving end, a node such as the digital VTR 3 can 
transmit data to the apparatus rapidly at the maximum 
transmission speed at which data transmission can be 
performed. Thus, there is no need to employ a bus man- 
ager entity to determine optimum speeds for each node 
and to transmit such information to each node every 
time a bus reconfiguration occurs. 
[0054] As stated earlier the methods of FIGS. 1 7 and 
18 establish the maximum transmission speeds for re- 
spective recipient devices by transmitting an asynchro- 
nous packet and receiving an acknowledgement. If iso- 
chronous data is to be subsequently transmitted to the 
recipient device, the same maximum speed information 
is preferably used for the isochronous transmission. 
[0055] In the case where a node such as the digital 
VTR 3 is connected between two or more devices (e.g., 
the MD deck 5 and the server 8 shown in FIG. 19) and 
controls isochronous data communication between 
those devices, the above-described methods of embod- 
iments of the present invention are also applicable. For 
instance, the digital VTR may check and compare max- 
imum asynchronous data communication speeds ena- 
bling satisfactory transmission for the two apparatuses. 
This can be accomplished by means of the digital VTR 
transmitting data asynchronously to one device at a time 
as in the method of FIG. 17 to determine a maximum 
transmission speed to each device. The digital VTR may 
then send each of the two devices a message indicating 
what speed should be set when transmitting to the other 
device. 

[0056] In the above description, the IEEE 1 394 serial 
bus has been used as an example, but embodiments of 
the present invention can be applied to other interfaces 
having similar features. Embodiments of the present in- 
vention are even applicable to a protocol that allows da- 
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ta transmission over a bus at a speed anywhere within 
a certain range. In such a case, the methods of FIGS. 
17 and 18 are performed in basically the same manner, 
starting at the high end of the range, and then gradually 
5 reducing the transmission speed in a step-wise manner 
by a predetermined amount in step S15 or S27 until an 
acknowledgement is received. 

[0057] Embod iments of the p resent invention also en- 
compass a storage medium, e.g., a CD-ROM, minidisk, 

10 floppy disk, etc., that stores a software program which 
is readable by processing circuitry of a node, such as 
by the CPU 25 of the digital VTR 3. The software pro- 
gram contains instructions for the processing circuitry to 
execute the above-described operations of FIGS. 17 

is and/or 18. 

[0058] While the present invention has been de- 
scribed above in reference to preferred embodiments 
thereof, it is understood that these embodiments are 
merely exemplary and that one skilled in the art can 

20 make many changes to the disclosed embodiments 
without departing from the spirit and scope of the inven- 
tion as defined by the appended claims. 



25 Claims 

1 . A method for transmitting data by a transmitting de- 
vice connected to a data bus, comprising the steps 

of: 

30 

(a) transmitting, by the transmitting device, a 
data packet onto said bus at a known speed, 
said data packet containing identification infor- 
mation of a target receiving end device con- 

35 nected to the bus: 

(b) detecting, by said transmitting device, 
whether an acknowledgement signal was sent 
by the receiving end device confirming receipt 
of the transmitted data packet: 

40 (c) if an acknowledgement signal is detected, 

setting a transmission speed for a subsequent 
data transmission by the transmitting device at 
the transmission speed of said transmitting 
step; and 

45 (d) if no acknowledgement, signal is detected, 

repeating step (a) at a reduced transmission 
speed and then repeating steps (b) and (c). 

2. The method according to claim 1, wherein said 
50 known speed is initially set to a maximum speed at 

which said transmitting device is capable of trans- 
mitting data. 

3. The method according to claim 1 , wherein said bus, 
55 said acknowledgement signal, and said known 

speed are each in accordance with the IEEE 
1394-1995 High Performance Serial Bus standard. 
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4. The method according to claim 3 : wherein said 
transmission speed is set in step (c) in the absence 
of a bus manager. 

5. The method according to claim 1 ; further compris- s 
ing storing said set transmission speed in a memory 

of said transmitting device in association with said 
receiving end device, and reading out said stored 
speed to be used as the speed for a subsequent 
data transmission to said receiving end device. 10 

6. The method according to claim 5 ; further compris- 
ing repeating steps (a), (b), (c) and (d) for a second 
receiving end device, and storing said speed set for 
said second receiving end device in said memory is 
in association therewith to be read out in conjunc- 
tion with a subsequent data transmission to said 
second receiving end device. 

7. The method according to claim 5, wherein said sub- 20 
sequent data transmission is an asynchronous data 
transmission. 

8. The method according to claim 5 : wherein said sub- 
sequent data transmission is an isochronous data 25 
transmission. 

9. The method according to claim 1, wherein said 
steps (a) : (b), (c), and (d) are performed following 

a bus reset operation of said bus. 30 

10. The method according to claim 5 : wherein said 
steps (a), (b), (c) and (d) are performed following a 
bus reset operation of said bus in which said mem- 
ory is cleared of transmission speed information. 35 

11. The method according to claim 1 : wherein said ac- 
knowledgement signal is a multi-bit digital signal. 

1 2. The method according to claim 1 : wherein said data -to 
packet is transmitted immediately after a successful 
arbitration for said bus by said transmitting device. 

13. The method according to claim 1, wherein said 
transmitting device is connected between at least 4 $ 
two other devices connected to said bus, and con- 
trols data transmission between said at least two 
other devices. 

14. An information processing apparatus connectable so 
to a bus, said information processing apparatus 
comprising: 



device confirming receipt of the transmitted da- 
ta: and 

transmission-speed setting means for setting a 
data transmission speed for said data transmis- 
sion means in accordance with at least one of 
a predefined condition of said bus and a condi- 
tion of the detection by said detecting means of 
said acknowledgement signal. 

15. The information processing apparatus according to 
claim 14 wherein said predefined condition of said 
bus is a bus reset condition. 

16. The information processing apparatus according to 
claim 14, further comprising transmission-speed 
storage means for storing the set transmission 
speed in association with said receiving end device. 

17. The information processing apparatus according to 
claim 16, wherein said data transmission means is 
configured to transmit data using a plurality of trans- 
mission methods, and said set data transmission 
speed is used when transmitting data to said receiv- 
ing end device using any one of said plurality of 
transmission methods. 

18. The information processing apparatus according to 
claim 17, wherein said plurality of transmission 
methods comprise an asynchronous data transmis- 
sion method and an isochronous data transmission 
method. 

19. The information processing apparatus according to 
claim 14, wherein said transmission speed setting 
means sets the data transmission speed in accord- 
ance with the condition of the detection by said de- 
tecting means of said acknowledgement signal. 

20. The information processing apparatus according to 
claim 14, wherein said apparatus is adapted to con- 
trol data transmission between at least two other 
devices when connected to said bus between said 
at least two other devices. 

21. An information processing method for an informa- 
tion processing apparatus connected to a bus, said 
information processing apparatus transmitting data 
to a receiving end apparatus via said bus, said in- 
formation processing method including: 

transmitting data to said receiving end appara- 
tus, which is connected to said bus: 
detecting an acknowledgement signal transmit- 
ted from the receiving end apparatus confirm- 
ing receipt of the transmitted data: and 
setting a data transmission speed for a subse- 
quent data transmission in accordance with at 
least one of a specific condition of said bus and 



data transmission means for transmitting data 
via said bus to a receiving end device connect- 5 $ 
ed to said bus: 

detecting means for detecting an acknowledge- 
ment signal transmitted from the receiving end 
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the condition of the detection of the acknowl- 
edgement signal. 

22. A storage medium readable by a machine, tangibly 
embodying program instructions executable by the s 
machine to carry out method steps for transmitting 
data by the machine operating as a transmitting de- 
vice connected to a data bus, said method steps 
comprising: 

10 

(a) transmitting, by the transmitting device, a 
data packet onto said bus at a known speed, 
said data packet containing identification infor- 
mation of a target receiving end device con- 
nected to the bus: 15 

(b) detecting, by said transmitting device, 
whether an acknowledgement signal was sent 
by the receiving end device confirming receipt 
of the transmitted data packet: 

(c) if an acknowledgement signal is detected, 20 
setting a transmission speed for a subsequent 
data transmission by the transmitting device at 

the transmitted speed of said transmitting step: 
and 

(d) if no acknowledgement signal is detected, 25 
repeating step (a) at a reduced transmission 
speed and then repeating steps (b) and (c). 

23. The storage medium according to claim 22, wherein 
said known speed is initially set to a maximum so 
speed at which said transmitting device is capable 

of transmitting data. 

24. The storage medium according to claim 22, wherein 
said bus, said acknowledgement signal, and said 35 
known speed are each in accordance with the IEEE 
1394-1995 High Performance Serial Bus standard. 
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FIG. 8 



node # 4 



root 
ch ch 



grant 









data prefix 




p 






leaf 





m 



node # 0 




node # 3 



deny |} 




node # 1 



node # 2 



19 



EP 0 971 508 A2 



FIG. 9 



node # 4 





data prefix data prefix || 



node # 0 



data prefix 



P 

branch 
ch ch 

7\ 




node # 3 



data 



prefix || 




node # 1 



node # 2 



20 



EP 0 971 508 A2 



FIG. 10 



TRANSMITTING END RECEIVING END 

LINK LAYER LINK LAYER 



REQUEST 




ACKNOWLEDGMENT 



21 



EP 0 971 508 A2 




22 



EP 0 971 508 A2 




23 



EP 0 971 508 A2 



FIG. 13 



transmitted first 



destination ID 



J I L 



It 



J I I ! L 



f I l 



rt tcode 



J I I I I I I — i — L 



pn 



sourceJD 
i i i I i i i L 



j L 



packed 
i i i 1 i i i i 



type specific information 

i i 1 i i i i i i i i i i i i i i i 



datajength 

i i i I i i i i 



extended tcode 



J L 



I I I 1 I f 



J 1 I I I i L 



J L 



l l I 



header_CRC 
i i I i i i i i 



t I i 



j I i l 



data field 



zero pad bytes (if necessary) 
i t i i 1 i i i t i t i I i t i L 



J L 



I t I I L 



data_CRC 
1 i i i i t t i 1 i i L 



i i l i i i i i i L 



transmitted last 



24 




EP 0 971 508 A2 



LL_ 











TYPE 
















CONTENTS 


RECEIVER NODE ID 


USED FOR COMPARISON REQUEST PACKET 
AND RESPONSE PACKET 


SPECIFY RETRANSMISSION METHOD 


SPECIFY PACKET TYPE AND TRANSACTION 


NOT USED FOR CABLE CONNECTION 


TRANSMITTER NODE ID 






CODE FOR DETECTING HEADER ERROR 




CODE FOR DETECTING DATA ERROR 


BIT 

LENGTHS 


CO 


CO 


CNJ 


■"3- 




to 






CVI 
CO 




CVI 

CO 


NAMES 


destination ID 






tcode 




source ID 






header CRC 


data field 


data CRC 
















ION 










PACKET ELEMENTS 


RECEIVER ID 


TRANSACTION 
LABEL 


RETRY CODE 


TRANSACTION CODE 


PRIORITY 


TRANSMITTER ID 


PACKET-TYPE INFORMAT 


PACKET-TYPE DATA 


HEADER CRC 


DATA BLOCK 


DATA BLOCK CRC 



25 



EP 0 971 508 A2 



FIG. 15 



transmitted first 



ack_code 
: i i 



ack_parity 
i i i 



transmitted last 



FIG. 16 



ack_complete 


TRANSMITTER NODE SUCCEEDED 
IN PACKET RECEPTION. 

fHO RESPONSE FROM TRANS-^1 
^ACTION LAYER J 


ack_pending 


TRANSMITTER NODE SUCCEEDED 
IN PACKET RECEPTION. 

f RESPONSE FROM TRANS-^ 
^ACTION LAYER J 


ack_busyX 


TRANSMITTER NODE WAS UNABLE 
TO RECIEVE PACKETS. 


ack_busyA 


TRANSMITTER NODE WAS UNABLE 
TO RECIEVE PACKETS. 


ack_busyB 


TRANSMITTER NODE WAS UNABLE 
TO RECIEVE PACKETS. 


ack_data_error 


TRANSMITTER NODE WAS UNABLE 
TO VERIFY PACKET CRC. 


ack_type_error 


PACKETS HAVING CONTENTS OUT 
OF SUPPORT ARRIVED. 



26 



EP 0 971 508 A2 



FIG. 17 



START J 



S11 



SET TRANSMITTABLE 
MAXIMUM TRANSMIS- 
SION SPEED 



TRANSMIT ASYNCHRO- 
NOUS DATA PACKET 



S12 




YES 




S15 



SET NEXT LOWER 

TRANSMISSION 

SPEED 



YES 



27 



EP 0 971 508 A2 



FIG. 18 




SET TRANSMITTABLE 
MAXIMUM TRANSMIS- 
SION SPEED 



S23 



SET STORED 

TRANSMISSION 

SPEED 



TRANSMIT ASYNCHRO- 
NOUS DATA PACKET 



S24 




SET NEXT LOWER 
TRANSMISSION 
SPEED 



YES 



28 



EP 0 971 508 A2 




EP 0 971 508 A2 



FIG. 20 



S400 





S400 



30 



